Towards an Enhanced Protocol for Improving Transactional Support in Interoperable Service Oriented Application-Based (SOA-Based) Systems

When using a shared database for distributed transactions, it is often difficult to connect business processes and softwarecomponents running on disparate platforms into a single transaction. For instance, one platform may add or update data, and thenanother platform later access the changed or added data. This severely limits transactional capabilities across platforms. Thissituation becomes more acute when concurrent transactions with interleaving operations spans across different applications andresources. Addressing this problem in an open, dynamic and distributed environment of web services poses special challenges,and still remains an open issue. Following the broad adoption and use of the standard Web Services Transaction Protocols,requirements have grown for the addition of extended protocols to handle problems that exist within the context of interoperableservice-oriented applications. Most extensions to the current standard WS-Transaction Protocols still lack proper mechanisms forerror-handling, concurrency control, transaction recovery, consolidation of multiple transaction calls into a single call, and securereporting and tracing for suspicious activities. In this research, we will first extend the current standard WS-TransactionFramework, and then propose an enhanced protocol (that can be deployed within the extended framework) to improvetransactional and security support for asynchronous applications in a distributed environment. A hybrid methodology whichincorporates service-oriented engineering and rapid application development will be used to develop a procurement system(which represents an interoperable service-oriented application) that integrates our proposed protocol. We will empiricallyevaluate and compare the performance of the enhanced protocol with other conventional distributed protocols (such as 2PL) interms of QoS parameters (throughput, response time, and resource utilization), availability of the application, databaseconsistency, and effect of locking on latency, among other factors.Keywords: Database, interoperability, security, concurrent transaction, web services, protocol, service-oriente

Securing the Deployment of Cloud-Hosted Services for Guaranteeing Multitenancy Isolation

Multitenancy introduces significant error and security challenges in the cloud depending on the location of the functionality to be shared and the required degree of isolation between the tenants. Existing approaches for securing the deployment of cloud-hosted services to serve multiple users have paid little attention to evaluating the effect of the varying degrees of multitenancy isolation on the security and access privilege of tenants (or components). In addition, approaches for securing the isolation of tenants (or components) are usually implemented at lower layers of the cloud stack and often apply to the entire system and not to individual tenants (or components). This study presents CLAMP (Cloud-based architectural approach for securing services through Multitenancy deployment Patterns) to securing the deployment of cloud-hosted services in a way that guarantees the required degree of isolation between the tenants. We evaluated the framework by applying it to a motivating cloud deployment problem. The findings show among other things that the framework can be used to select suitable deployment patterns, evaluate the effect of varying degrees of isolation on the cloud-hosted service, analyse the deployment requirements of cloud-hosted services and optimise the deployment of the cloud-hosted service to guarantee multitenancy isolation

Architecting the deployment of cloud-hosted services for guaranteeing multitenancy isolation.

In recent years, software tools used for Global Software Development (GSD) processes (e.g., continuous integration, version control and bug tracking) are increasingly being deployed in the cloud to serve multiple users. Multitenancy is an important architectural property in cloud computing in which a single instance of an application is used to serve multiple users. There are two key challenges of implementing multitenancy: (i) ensuring isolation either between multiple tenants accessing the service or components designed (or integrated) with the service; and (ii) resolving trade-offs between varying degrees of isolation between tenants or components. The aim of this thesis is to investigate how to architect the deployment of cloud-hosted service while guaranteeing the required degree of multitenancy isolation. Existing approaches for architecting the deployment of cloud-hosted services to serve multiple users have paid little attention to evaluating the effect of the varying degrees of multitenancy isolation on the required performance, resource consumption and access privilege of tenants (or components). Approaches for isolating tenants (or components) are usually implemented at lower layers of the cloud stack and often apply to the entire system and not to individual tenants (or components). This thesis adopts a multimethod research strategy to providing a set of novel approaches for addressing these problems. Firstly, a taxonomy of deployment patterns and a general process, CLIP (CLoud-based Identification process for deployment Patterns) was developed for guiding architects in selecting applicable cloud deployment patterns (together with the supporting technologies) using the taxonomy for deploying services to the cloud. Secondly, an approach named COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) was developed together with supporting algorithms and then applied to three case studies to empirically evaluate the varying degrees of isolation between tenants enabled by multitenancy patterns for three different cloud-hosted GSD processes, namely-continuous integration, version control, and bug tracking. After that, a synthesis of findings from the three case studies was carried out to provide an explanatory framework and new insights about varying degrees of multitenancy isolation. Thirdly, a model-based decision support system together with four variants of a metaheuristic solution was developed for solving the model to provide an optimal solution for deploying components of a cloud-hosted application with guarantees for multitenancy isolation. By creating and applying the taxonomy, it was learnt that most deployment patterns are related and can be implemented by combining with others, for example, in hybrid deployment scenarios to integrate data residing in multiple clouds. It has been argued that the shared component is better for reducing resource consumption while the dedicated component is better in avoiding performance interference. However, as the experimental results show, there are certain GSD processes where that might not necessarily be so, for example, in version control, where additional copies of the files are created in the repository, thus consuming more disk space. Over time, performance begins to degrade as more time is spent searching across many files on the disk. Extensive performance evaluation of the model-based decision support system showed that the optimal solutions obtained had low variability and percent deviation, and were produced with low computational effort when compared to a given target solution

A framework for achieving the required degree of multitenancy isolation for deploying components of a cloud-hosted service.

Multitenancy allows multiple tenants to access a single instance of a cloud offering. While several approaches exist for implementing multitenancy, little attention has been paid to implementing the required degree of isolation since there are varying degrees of isolation that can be implemented for each tenant. This paper presents a framework for achieving the required degree of isolation between tenants accessing a cloud offering so that the required performance, resource utilisation and access privilege of one tenant does not affect other tenants when there are workload changes. The framework is composed of two main constituents: 1) component-based approach to multitenancy isolation through request re-routing (COMITRE); 2) an optimisation model for providing optimal solutions for deploying components of a cloud-hosted service. We demonstrate using a case study of: 1) a cloud-hosted bug tracking system; 2) a synthetic dataset, the possibility of providing the required degree of isolation and optimal deployment solutions

Evolutionary computation for optimal component deployment with multitenancy isolation in cloud-hosted applications.

A multitenant cloud-application that is designed to use several components needs to implement the required degree of isolation between the components when the workload changes. The highest degree of isolation results in high resource consumption and running cost per component. A low degree of isolation allows sharing of resources, but leads to degradation in performance and to increased security vulnerability. This paper presents a simulation-based approach operating on computational metaheuristics that search for optimal ways of deploying components of a cloud-hosted application to guarantee multitenancy isolation When the workload changes, an open multiclass Queuing Network model is used to determine the average number of component access requests, followed by a metaheuristic search for the optimal deployment solutions of the components in question. The simulation-based evaluation of optimization performance showed that the solutions obtained were very close to the target solution. Various recommendations and best practice guidelines for deploying components in a way that guarantees the required degree of isolation are also provided

Evaluating degrees of multitenancy isolation: a case study of cloud-hosted GSD tools.

Multitenancy is an essential cloud computing property where a single instance of an application serves multiple tenants. Multitenancy introduces significant challenges when deploying application components to the cloud due to the demand for different degrees of isolation between tenants. At the very basic degree of isolation, tenants still share application components as much as possible. However, while some components may benefit from low degree of isolation between tenants, others may need a higher degree of isolation, for instance, in a situation where a component is too critical to be shared, or needs to be configured specifically for individual tenants. This paper describes COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) for cloud-hosted Global Software Development (GSD) tools. We developed a multitenant component for each multitenancy pattern, integrated it within Hudson, and then compared their impact on different tenants. The study revealed among other things that a component deployed based on shared component offers a lower degree of tenant isolation (than tenant-isolated component and dedicated component) when one of the tenants is exposed to a demanding deployment condition (e.g, large instant loads). We also provide some recommendations to guide an architect in implementing multitenancy isolation on a set of GSD tools: Hudson, Subversion and Bugzilla

Evaluating degrees of isolation between tenants enabled by multitenancy patterns for cloud-hosted version control systems (VCS).

When implementing multitenancy for cloud-hosted applications, one of the main challenges to overcome is how to enable the required degree of isolation between tenants so that the required performance, resource utilization, and access privileges of one tenant does not affect other tenants. This paper applies COMITRE (COmponent-based approach to Multitenancy Isolation Through request RE-routing) to empirically evaluate the degree of isolation between tenants enabled by multitenancy patterns for cloud-hosted Version Control System (VCS). We implemented three multitenancy patterns (i.e., shared component, tenant-isolated component, and dedicated component) by developing a multitenant component using the FileSystem SCM plugin integrated within Hudson. The study confirmed that dedicated component provides the highest degree of isolation between tenants (compared to shared component and tenant-isolated component) in terms of error% (i.e., the percentage oferrors with unacceptably slow response times) and throughput. The system load of tenants showed no variability, and hence did not influence the degree of tenant isolation for all the three multitenancy patterns. We also provide a summary of recommended multitenancy patterns for optimizing performance and utilization of resources for cloud-hosted software services, as well as recommendations to guide an architect in implementing multitenancy isolation on similar VCS tools like Subversion and CVS

A model for optimising the deployment of cloud-hosted application components for guaranteeing multitenancy isolation.

Tenants associated with a cloud-hosted application seek to reduce running costs and minimize resource consumption by sharing components and resources. However, despite the benefits, sharing resources can affect tenant’s access and overall performance if one tenant abruptly experiences a significant workload, particularly if the application fails to accommodate this sudden increase in workload. In cases where a there is a higher or varying degree of isolation between components, this issue can become severe. This paper aims to present novel solutions for deploying components of a cloud-hosted application with the purpose of guaranteeing the required degree of multitenancy isolation through a mathematical optimization model and metaheuristic algorithm. Research conducted through this paper demonstrates that, when compared, optimal solutions achieved through the model had low variability levels and percent deviation. This paper additionally provides areas of application of our optimization model as well as challenges and recommendations for deploying components associated with varying degrees of isolation

Evaluating the effect of locking on multitenancy isolation for components of cloud-hosted services.

Multitenancy isolation is a way of ensuring that the performance, stored data volume and access privileges required by one tenant and/or component does not affect other tenants and/or components. One of the conditions that can influence the varying degrees of isolation is when locking is enabled for a process or component that is being shared. Although the concept of locking has been extensively studied in database management, there is little or no research on how locking affects multitenancy isolation and its implications for optimizing the deployment of components of a cloud-hosted service in response to workload changes. This paper applies COMITRE (Component-based approach to Multitenancy Isolation through Request Re-routing) to evaluate the impact of enabling locking for a shared process or component of a cloud-hosted application. Results show that locking has a significant effect on the performance and resource consumption of tenants especially for operations that interact directly with the local file system of the platform used on the cloud infrastructure. We also present recommendations for achieving the required degree of multitenancy isolation when locking is enabled for three software processes: continuous integration, version control, and bug tracking

Boostig Ensemble Model for Predicting Hepatitis C (BEM-HC))

No Abstrac